With tsconfig include: ['src/**/*'], tsc infers rootDir as src/, so the
compiled main.js sits directly at dist/apps/<name>/main.js — not under
a src/ subdir. Matches the path assertion used by the existing webpack
monorepo test in build.command.e2e-spec.ts.

…ests

Existing closeWatchers and onSuccess tests need an additional
mockReturnValueOnce([]) entry to account for the new
includeLibraryAssets getValueOrDefault call introduced by this PR.
Without it, the mock chain shifts and tests fail with TypeError when
sourceRoot resolves to a non-string.

Add an opt-in --format flag to nest generate and nest new commands.
When passed, the format option is propagated to the schematic so it
can format generated files (e.g. with Prettier) before writing them
to disk. The default is off, so no existing project behavior changes
unless the flag is explicitly enabled.

This is the CLI-side change. The actual formatting logic lives in
@nestjs/schematics.

Closes #316

Exercises two paths through the format option wiring:
- nest generate controller <name> --no-format -> format=false is
  accepted and the controller is still generated.
- nest generate controller <name> (flag omitted) -> format
  defaults to true and the controller is generated.

The tests do not assert that prettier formatting has actually been
applied because the companion @nestjs/schematics change lives on a
separate major release line; here we only want to guarantee the CLI
parses the flag and passes it through without regressing other
generate paths.

feat(generate): pass format option to schematics

The `getRspackConfigPath` helper already honours `cmdOptions.rspackPath`
and its unit tests cover the CLI-path precedence case, but neither the
`build` nor the `start` command wires the flag through from commander.
As a result, projects using the rspack builder could only point at a
custom rspack config via `nest-cli.json`, with no equivalent of the
existing `--webpackPath` CLI option.

Mirror the existing `--webpackPath` pattern:

- register `--rspackPath [path]` on both `build` and `start` commands
- forward `options.rspackPath` into the respective command contexts
- extend the `BuildCommandContext` / `StartCommandContext` interfaces

Also adds a unit test confirming the option flows from the build action
into `getRspackConfigPath`.

`retrieveCols` (used to center-pad the post-install banner printed after
`nest new`) only asked the shell for the terminal width via `tput cols`.
On Windows, `tput` is not installed by default, so the call always threw
and the function silently fell back to the hard-coded 80 columns — even
for users with wider terminals. The same fallback also kicks in whenever
`tput` is missing from a sandboxed or minimal Linux image.

Ask Node first: `process.stdout.columns` is maintained by the runtime on
every platform and reflects the actual terminal width (or `undefined` /
`0` when stdout is not a TTY). When it is a positive number, use it
directly and skip the `execSync` call entirely — this removes a small
per-invocation process spawn as well. Keep the existing `tput cols`
path and the 80-column default as secondary/tertiary fallbacks for the
non-TTY case.

Also adds unit tests covering the three branches (stdout.columns set,
tput fallback, and the final default).

Backports the master-branch fix for #3229 (PR #3275) to v12.0.0. The
`@nestjs/schematics` resource generator defines `--type` and `--crud`
options in its schema.json, but the v12 CLI does not register either
flag on the `generate` command. Running:

    nest g resource users --type rest --crud

exits with "error: unknown option '--type'" even though the schematic
itself would handle both flags correctly.

- register `--type [type]` and `--crud` on the generate command
- forward both into the generate action and on to the schematic
- only forward `--crud` when explicitly passed (avoid toggling default
  behavior on users who never opted in)

The master-branch PR noted that "no automated tests were added because
there are no existing e2e tests for generate resource" — this PR adds a
focused unit spec for `GenerateAction` covering forwarding of the new
options individually and together.

feat(generate): accept type and crud options on the resource schematic

fix(new): prefer process.stdout.columns over tput for terminal width

feat(cli): add rspack config path option to build and start commands

…aries

feat(assets): add option to include library assets in app builds

feat(package-managers): add bun support

…odenext resolution (#3364)

Under `moduleResolution: 'node16'` or `'nodenext'`, ESM-style imports
require explicit file extensions. The PluginMetadataGenerator previously
emitted dynamic `import("./hello.dto")` calls without an extension,
causing TypeScript diagnostics in the generated metadata file and
`ERR_MODULE_NOT_FOUND` at runtime when the metadata is executed.

Detect the consuming project's `moduleResolution` from the supplied
`ts.Program` and, when it is Node16 or NodeNext, walk both the
collected metadata AST and the visitor `typeImports` map to append
`.js` to relative specifiers that lack an extension. Bare specifiers,
absolute paths, and already-extended specifiers (`.js`, `.mjs`, `.cjs`,
`.json`, ...) are left untouched, so projects using classic / node10 /
bundler resolution are unaffected.

Closes #3364

v12.0.0 runs vitest without globals enabled, so the new spec needs to
import `describe`, `expect`, `it` explicitly. CI was failing with
`ReferenceError: describe is not defined` at file load time, which
caused the whole spec to be skipped.

After this change, all 18 cases in the spec pass alongside the existing
suite.

…Dir (#3387)

When `--path` (or any tsconfig override) results in an emit whose
`rootDir` differs from the configured `sourceRoot`, AssetsManager
currently strips asset paths against `sourceRoot`, leaving copied
assets one level above where the emitted JavaScript ended up.

Computes the effective rootDir the same way the TypeScript compiler
does — explicit `compilerOptions.rootDir` when set, otherwise the
longest common parent directory of the input file list — and uses it
as the strip root for application assets. Library assets keep the
per-library `_sourceRoot` introduced for `includeLibraryAssets` so
their layout is unchanged.

This is a re-implementation of #3403 on top of v12.0.0 (vitest tests,
library-assets-aware AssetsManager, debounced watch onSuccess).

…754525b

fix(plugin-metadata): emit .js extensions for dynamic imports under nodenext (#3364)

fix(build): align asset path stripping with effective TypeScript rootDir (#3387)

`nest info` walks the project `package.json` and lists every `@nestjs/*`
dependency it finds. The dependency list flows through `format()`, which
sorted the entries and then read `sorted[0].name.length` to compute a
column width — without first checking that the list was non-empty.

When `package.json` was readable but contained zero `@nestjs/*` entries
(running `nest info` from a non-Nest project, or from a fresh checkout
where dependencies have not been installed yet), `format([])` threw
`Cannot read properties of undefined (reading 'name')`. That exception
bubbled up to the outer `try/catch` in `displayNestInformationFromPackage`
and was silently relabeled as `NEST_INFORMATION_PACKAGE_MANAGER_FAILED`:

    smirk  cannot read your project package.json file,
    are you inside your project directory?

…which is a flat-out lie when the read itself succeeded, and sends users
hunting for a non-existent file/directory issue.

Fix it in two complementary places so the contract is right end-to-end:

* `format()` is now defensive — it returns an empty array unchanged
  instead of dereferencing `sorted[0]`. This means the helper is safe
  to call with any input, including from tests.
* `displayNestVersions()` short-circuits for an empty list and prints
  an honest, actionable message
  (`No @nestjs/* dependencies were found in package.json.`) instead of
  letting an exception fall into the misleading package-manager catch.

Tests cover both: `format([])` no longer throws, the existing
non-empty padding/version-range cleanup still works, and
`displayNestVersions({})` writes the new explanatory line.

Replace stray jest.Mock casts in the bun lock-file tests with vitest's
Mock type that the surrounding tests already use. The casts were left over
from #3258 and reference a global that does not exist on v12 (tests pass
at runtime only because vitest does not type-check by default).

Also add a unit test for the existing catch branch in
PackageManagerFactory.find that falls back to NpmPackageManager when
fs.promises.readdir rejects, so the behaviour is locked in.

The existing plugins-loader spec exercised only the most common shape: a
plugin exporting both `before` and `after` transformer factories. It left
several user-visible contracts of `PluginsLoader.load` untested:

- A plugin that exports only `afterDeclarations` is still valid and must
  produce an entry in `afterDeclarationsHooks` (not in beforeHooks /
  afterHooks).
- When a plugin exports a `ReadonlyVisitor` class, the loader must
  instantiate it with the merged user options + extras + `readonly: true`
  and stamp the plugin name onto `instance.key` so downstream metadata
  generation can identify the visitor.
- The `extras.pathToSource` argument must reach the visitor constructor.
- The bound hooks returned in `MultiNestCompilerPlugins` must, when called
  with a `ts.Program`, invoke the original transformer factory with the
  user-supplied options as the first argument and the program as the
  second.
- Plugin order in the input array must be preserved across the returned
  hook arrays.

These behaviors are relied on by `compiler.ts`, `watch-compiler.ts`,
`swc-compiler.ts`, `forked-type-checker.ts`, and the metadata pipeline,
so a regression in any of them would silently break swagger/graphql
plugin integration.

No production code is touched.

…age-v12

test(plugins-loader): cover declaration hooks and visitor wiring

…ry-jest-mock

test(package-managers): use vitest mock type and cover readdir rejection

fix(info): show clear message when no @nestjs/* deps are declared